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Abstract 
This document describes Information Elements related to the data link 
layer. They are used by the IP Flow Information Export (IPFIX) 
protocol for encoding measured data link layer traffic information. 
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Introduction 


Ethernet [IEEE802.1D] and VLAN (Virtual LAN) technologies had been 
used only in Local Area Networks. Recently, they have been used in 
Wide Area Networks, e.g., Layer 2 VPN (L2 VPN) services. 
Accordingly, carrier networks using VLAN technologies have been 
enhanced to Provider Bridged Networks and Provider Backbone Bridged 
Networks [IEEE802.10]. In addition, Ethernet in data centers has 
also been enhanced for server virtualization and input/output (1/0) 
consolidation. 


While these innovations provide flexibility, scalability, and 
mobility to an existing network architecture, they increase the 
complexity of traffic measurement due to the existence of various 
Ethernet header formats. To cope with this, a more sophisticated 
method of traffic measurement is required. 


IPFIX and Packet Sampling (PSAMP) help to resolve these problems. 
However, the PSAMP Information Model [RFC5477] and the IPFIX 
Information Model [RFC7011] don’t yet contain enough Information 
Elements related to the data link layer, e.g., Ethernet header forms. 
This document describes existing and new Information Elements related 
to data link layers that enable a more sophisticated traffic 
measurement method. 


Note that this document does not update [RFC5477] or [RFC7011] 
because IANA’s IPFIX registry [IANA-IPFIX] is the ultimate 
Information Element reference, per Section 1 of [RFC7012]. 


1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


Extended Ethernet Technology 


1. Wide-Area Ethernet Technology Summary 


Provider Bridge and Provider Backbone Bridge [IEEE802.10], which are 
standards for Wide-Area Ethernet, are described below. 


o In Provider Bridge [IEEE802.10], there are two VLAN IDs: Service 
VLAN Identifier (S-VID) and Customer VLAN Identifier (C-VID). 
S-VID is assigned to an Ethernet frame by a service provider, 
while C-VID is independently assigned to an Ethernet frame by a 
customer. Frame switching in a service provider network is based 
on only S-VID. 
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o In Provider Backbone Bridge [IEEE802.10], new Ethernet fields, 
such as Backbone VLAN Identifier (B-VID) and Backbone Service 
Instance Identifier (I-SID), are introduced to overcome the 
limitations on the VLAN identifier space and to isolate the 
service provider and customer identifier spaces. Frame switching 
is based on a 12-bit B-VID, and customer identification is based 
on a 24-bit I-SID. A flexible network design has become possible 
because network management is separated from customer management. 
Other Ethernet fields that indicate quality of service (QoS) class 
are Backbone VLAN Priority Code Point (B-PCP), Backbone VLAN Drop 
Eligible Indicator (B-DEI), Backbone Service Instance Priority 
Code Point (I-PCP), and Backbone Service Instance Drop Eligible 
Indicator (I-DEI). 


The Provider Backbone Bridge technologies have enhanced a Wide-Area 
Ethernet service from a flat network to a hierarchical network 
consisting of a Provider Bridged Network and Provider Backbone 
Bridged Network. 

Frame formats used in Wide-Area Ethernet are shown in Appendix A. 


2.2. Virtual Ethernet Technology Summary 


There have been several challenges in the existing virtual switches 


environment in a data center. One is the lack of network management 
visibility: limited features on virtual switches make it difficult to 
monitor traffic among virtual machines (VMs). Another is the lack of 


management scalability and flexibility: increasing the number of VMs 
for multi-tenant architecture causes an increase in the number of 
virtual switches and in the number of the traffic control policies, 
which reach the limitations of network management scalability and 
flexibility. 


In this situation, the IEEE 802.1 working group is standardizing 
virtual bridging technologies such as Edge Virtual Bridging (EVB), 
including two kinds of Edge Relays: Virtual Edge Bridge (VEB) and 


Virtual Edge Port Aggregator (VEPA) [IEEE802.10bg]. The VEB is a 
bridge that provides bridging among multiple VMs and the external 
bridging environment. The VEPA is a bridge-like device on a host 


that forwards all internal traffic to the adjacent EVB bridge and 
then distributes any traffic received from the adjacent EVB bridge to 
VMs. The VEPA makes all the VM-to-VM traffic visible to the EVB 
bridge so that the traffic can be monitored and so that the EVB 
bridge can apply filtering to the traffic. 


To improve flexibility, a virtual link between a host system and EVB 


bridge is standardized as S-channel. S-channel allows a bridge to 
treat the traffic in the virtual link as if it comes in on a separate 
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port. For example, in the host, an S-channel may be attached to a 
VEB or a VEPA or directly to an internal port in order to apply each 
port-based filtering rule to the traffic. S-channel over the link 
between a host and its adjacent bridge uses Service VLAN Tag (S-TAG) 
[IEEE802.10]. When S-channel is in use, frames on the link carry an 
S-TAG to identify the S-channel. 


On the other hand, Bridge Port Extension emulates single Extended 
Bridge from multiple physical switches and virtual switches, and it 
also simplifies network management. Also, it solves the lack of 
network management visibility by forwarding all traffic into a 
central Controlling Bridge using E-channel. E-channel over the link 
between a Bridge Port Extender and a Controlling Bridge uses E-TAG 
defined in [IEEE802.1BR]. 


Traffic monitoring over S-channel and E-channel is required in order 
to get visibility of VM-to-VM traffic and visibility of each 
channel’s traffic on a virtual link. 


Frame formats with E-TAG used in E-channel and S-TAG used in 
S-channel are shown in Appendix A. Though these frames carry special 
tags while on the link, those tags identify a virtual port (or for 
multicast in the downstream direction, a set of virtual ports) to 
which they are destined. These tag values only have local meaning, 
and the Flow would be reported as sent and arriving on the 
corresponding virtual ports. Therefore, IPFIX does not need to 
monitor data based on these tags. 


3. Modification and Addition of Information Elements Related to Data 
Link Layer 


The Information Elements listed in the upper section of Table 1 are 
necessary for enabling IPFIX and PSAMP traffic measurement for the 
data link layer, which is not limited to Ethernet because the method 
can be applied to other data link protocols as well. 


Information Elements in the middle section of Table 1 are necessary 
for enabling the IPFIX and PSAMP traffic measurement for 
[IEEE802.10]. 


Information Elements in the lower section of Table 1 are octet 


counter or packet length for layer 2, and they are necessary for 
enabling IPFIX and PSAMP traffic measurement for the data link layer. 
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rara = 十 
| ID | Name | 
prenne AO a Ka ERAT A 十 
| 312 | dataLinkFrameSize | 
| 315 | dataLinkFrameSection | 
| 408 | dataLinkFrameType | 
| 409 | sectionOffset | 
| 410 | sectionExportedOctets 
hea dE EE ET oe + 
| 411 | dotlqServiceInstanceTag 
| 412 | dotlqServiceInstanceld 
| 413 | dotlqServiceInstancePriority | 
| 414 | dotlqCustomerSourceMacAddress | 
| 415 | dotlqCustomerDestinationMacAddress | 
ezr Ka + 
352 layer20ctetDeltaCount 
353 layer20ctetTotalCount 
| 417 | postL20ctetDeltaCount | 
| 418 | postMCastL20ctetDeltaCount 
| 420 | postL20ctetTotalCount 
| 421 | postMCastL20ctetTotalCount | 
422 minimumL2TotalLength 
| 423 | maximumL2TotalLength 
| 424 | droppedL20ctetDeltaCount 
| 425 | droppedL20ctetTotalCount 
| 426 | ignoredL20ctetTotalCount | 
| 427 | notSentL20ctetTotalCount 
428 layer20ctetDeltaSumOfSquares | 
| 429 | layer20ctetTotalSumOfSquares 
| 430 | layer2FrameDeltaCount | 
| 431 | layer2FrameTotalCount | 
Tate aaa EA a a + 


Table 1: Information Elements Related to Data Link Layer 
3.1. Existing Information Elements 
Some existing Information Elements are required for data link layer 
export. Their details are reproduced here from IANA’s IPFIX registry 
[IANA-IPFIX]. Additions per this document appear between *. 
Section 3.1.1 introduces the missing Data Type Semantics for the 


dataLinkFrameSize Information Element, which is held to be an 
interoperable change per #4 in Section 5.2 of [RFC7013]. 
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Section 3.1.2 extends the definition of the dataLinkFrameSection 
Information Element with reference to the new sectionOffset 
Information Element, which is also an interoperable change per #4 in 
Section 5.2 of [RFC7013]. 


The layer20ctetDeltaCount Information Element reports the number of 
layer 2 octets since the previous report in incoming packets for this 
Flow, while the layer20ctetTotalCount Information Element reports the 
total number of layer 2 octets in incoming packets for this Flow. 

The layer2FrameDeltaCount Information Element reports the number of 
incoming layer 2 frames since the previous report for this Flow, 
while layer2FrameTotalCount Information Element reports the total 
number of incoming layer 2 frames for this Flow. All of these 
Information Elements are unchanged from the existing IANA 
[IANA-IPFIX] definitions, and are reproduced in Section 3.1.3 through 
Section 3.1.6 below for completeness. 


Therefore, these changes do not introduce any backward-compatibility 
issues. 


Per Section 5.2 of [RFC7013], for each of these changes, [RFC7133] 
has been appended to the requester in IANA’s IPFIX registry 
[IANA-IPFIX], the Information Element’s revision number has been 
incremented by one, and the Information Element’s revision date 
column has been updated. 

3.1.1. dataLinkFrameSize 


Description: 


This Information Element specifies the length of the selected data 
link frame. 


The data link layer is defined in [ISO/IEC.7498-1:1994]. 
Abstract Data Type: unsignedl6 
*Data Type Semantics: quantity* 
ElementId: 312 
References: [ISO/IEC.7498-1:1994] 


Status: current 
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3.1.2. dataLinkFrameSection 
Description: 


This Information Element carries n octets from the data link frame 
of a selected frame, starting sectionOffset octets into the frame. 


*However, if no sectionOffset field corresponding to this 
Information Element is present, then a sectionOffset of zero 
applies, and the octets MUST be from the start of the data link 
frame. X 


The sectionExportedOctets expresses how much data was observed, 
while the remainder is padding. 


When the sectionExportedOctets field corresponding to this 
Information Element exists, this Information Element MAY have a 
fixed length and MAY be padded, or it MAY have a variable length. 


When the sectionExportedOctets field corresponding to this 
Information Element does not exist, this Information Element 
SHOULD have a variable length and MUST NOT be padded. In this 
case, the size of the exported section may be constrained due to 
limitations in the IPFIX protocol. 


Further Information Elements, i.e., dataLinkFrameType and 
dataLinkFrameSize, are needed to specify the data link type and 
the size of the data link frame of this Information Element. A 
set of these Information Elements MAY be contained in a structured 
data type, as expressed in [RFC6313]. Or a set of these 
Information Elements MAY be contained in one Flow Record as shown 
in Appendix B of [RFC7133]. 
The data link layer is defined in [ISO/IEC.7498-1:1994]. 

Abstract Data Type: octetArray 

Elementld: 315 

References: [RFC6313] [RFC7133] [ISO/IEC.7498-1:1994] 

Status: current 

3.1.3. layer20ctetDeltaCount 
The layer20ctetDeltaCount Information Element is unchanged from the 


existing IANA [IANA-IPFIX] definition and is reproduced here for 
reference only. 
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Description 
The number of layer 2 octets since the previous report (if any) in 
incoming packets for this Flow at the Observation Point. The 
number of octets includes layer 2 header(s) and layer 2 payload. 

Abstract Data Type: unsigned64 

Data Type Semantics: deltaCounter 

Units: octets 

ElementId: 352 

Status: current 

3.1.4. layer2OctetTotalCount 

The layer20ctetTotalCount Information Element is unchanged from the 

existing IANA [IANA-IPFIX] definition and is reproduced here for 

reference only. 

Description: 
The total number of layer 2 octets in incoming packets for this 
Flow at the Observation Point since the Metering Process 
(re-)initialization for this Observation Point. The number of 
octets includes layer 2 header(s) and layer 2 payload. 

Abstract Data Type: unsigned64 

Data Type Semantics: totalCounter 

Units: octets 

Elementld: 353 

Status: current 

3.1.5. layer2FrameDeltaCount 
The layer2FrameDeltaCount Information Element is unchanged from the 


existing IANA [IANA-IPFIX] definition and is reproduced here for 
reference only. 
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Description: 


The number of incoming layer 2 frames since the previous report 
(if any) for this Flow at the Observation Point. 


Abstract Data Type: unsigned64 

Data Type Semantics: deltaCounter 

Units: frames 

ElementId: 430 

Status: current 

3.1.6. layer2FrameTotalCount 

The layer2FrameTotalCount Information Element is unchanged from the 

existing IANA [IANA-IPFIX] definition and is reproduced here for 

reference only. 

Description: 
The total number of incoming layer 2 frames for this Flow at the 
Observation Point since the Metering Process (re-)initialization 
for this Observation Point. 

Abstract Data Type: unsigned64 

Data Type Semantics: totalCounter 

Units: frames 

Elementld: 431 

Status: current 


3.2. New Information Elements 


The following new Information Elements have been added for data link 
layer monitoring. 


In IANA’s IPFIX registry [IANA-IPFIX], the Requester has been set to 
[RFC7133], the Information Element’s Revision has been set to zero, 
and the Information Element’s Date set to the date upon which the new 
Information Elements have been added to the registry. All other 
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3 


3 


2s 


.2 


columns that are not explicitly mentioned below (e.g., Units, Range, 
References) are not applicable and are to be left blank since the 
registry does not explicitly record "not applicable". 


1. 


dataLinkFrameType 


Description: 


This Information Element specifies the type of the selected data 
link frame. 


The following data link types are defined here: 


— 0x01 IEEE802.3 ETHERNET [IEEE802.3] 


— 0x02 IEEE802.11 MAC Frame format [IEEE802.11] 
Further values may be assigned by IANA. Note that the assigned 
values are bits so that multiple observations can be OR'd 


together. 


The data link layer is defined in [ISO/IEC.7498-1:1994]. 


Abstract Data Type: unsignedl6 


Data Type Semantics: flags 


ElementId: 408 


References: [IEEE802.3] [IEEE802.11] [ISO/IEC.7498-1:1994] 


Status: current 


ESA 


sectionOffset 


Description: 


This Information Element specifies the offset of the packet 
section (e.g., dataLinkFrameSection, ipHeaderPacketSection, 
ipPayloadPacketSection, mplsLabelStackSection, and 
mplsPayloadPacketSection). If this Information Element is 
omitted, it defaults to zero (i.e., no offset). 


If multiple sectionOffset Information Elements are specified 
within a single Template, then they apply to the packet section 
Information Elements in order: the first sectionOffset applies to 
the first packet section, the second to the second, and so on. 
Note that the "closest" sectionOffset and packet section 
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Information Elements within a given Template are not necessarily 
related. If there are fewer sectionOffset Information Elements 
than packet section Information Elements, then subsequent packet 
section Information Elements have no offset, i.e., a sectionOffset 
of zero applies to those packet section Information Elements. If 
there are more sectionOffset Information Elements than the number 
of packet section Information Elements, then the additional 
sectionOffset Information Elements are meaningless. 

Abstract Data Type: unsignedl6 

Data Type Semantics: quantity 

ElementId: 409 

Status: current 

3.2.3. sectionExportedOctets 

Description: 
This Information Element specifies the observed length of the 
packet section (e.g., dataLinkFrameSection, ipHeaderPacketSection, 
ipPayloadPacketSection, mplsLabelStackSection, and 
mplsPayloadPacketSection) when padding is used. 
The packet section may be of a fixed size larger than the 
sectionExportedOctets. In this case, octets in the packet section 
beyond the sectionExportedOctets MUST follow the [RFC7011] rules 
for padding (i.e., be composed of zero (0) valued octets). 

Abstract Data Type: unsignedl6 

Data Type Semantics: quantity 

Elementld: 410 

References: [RFC7011] 

Status: current 

3.2.4. dotlqServiceInstanceTag 

Description: 

This Information Element, which is 16 octets long, represents the 


Backbone Service Instance Tag (I-TAG) Tag Control Information 
(TCI) field of an Ethernet frame as described in [IEEE802.10]. It 
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encodes the Backbone Service Instance Priority Code Point (I-PCP), 
Backbone Service Instance Drop Eligible Indicator (I-DEI), Use 
Customer Addresses (UCAs), Backbone Service Instance Identifier 
(I-SID), Encapsulated Customer Destination Address (C-DA), 
Encapsulated Customer Source Address (C-SA), and reserved fields. 
The structure and semantics within the Tag Control Information 
field are defined in [IEEE802.10]. 

Abstract Data Type: octetArray 

Data Type Semantics: default 

ElementId: 411 

References: [IEEE802.10] 

Status: current 


.2.5. dotlgServicelnstanceld 


Description: 
The value of the 24-bit Backbone Service Instance Identifier 
(I-SID) portion of the Backbone Service Instance Tag (I-TAG) Tag 
Control Information (TCI) field of an Ethernet frame as described 
in [IEEE802.10]. 

Abstract Data Type: unsigned32 

Data Type Semantics: identifier 

ElementId: 412 

References: [IEEE802.10] 

Status: current 

Range: The valid range is 0 - 16777215 (i.e., 24 bits). 

.2.6. dotlqServiceInstancePriority 


Description: 


The value of the 3-bit Backbone Service Instance Priority Code 
Point (I-PCP) portion of the Backbone Service Instance Tag (I-TAG) 
Tag Control Information (TCI) field of an Ethernet frame as 
described in [IEEE802.10]. 
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Abstract Data Type: unsigned8 

Data Type Semantics: identifier 

Elementld: 413 

References: [IEEE802.10] 

Status: current 

Range: The valid range is 0-7. 
3.2.7. dotlaqCustomerSourceMacAddress 


Description: 


The value of the Encapsulated Customer Source Address (C-SA) 
portion of the Backbone Service Instance Tag (I-TAG) 
Information (TCI) 
[IEEE802.10]. 


Tag Control 
field of an Ethernet frame as described in 


Abstract Data Type: macAddress 
Data Type Semantics: default 
ElementId: 414 

References: [IEEE802.10] 
Status: current 


3.2.8. dotlqCustomerDestinationMacAddress 


Description: 


The value of the Encapsulated Customer Destination Address (C-DA) 
portion of the Backbone Service Instance Tag (I-TAG) 
Information (TCI) 
[IEEE802.10]. 


Tag Control 
field of an Ethernet frame as described in 


Abstract Data Type: macAddress 
Data Type Semantics: default 


ElementId: 415 
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References: [IEEE802.10] 
Status: current 
3.2.9. postL20ctetDeltaCount 
Description: 
The definition of this Information Element is identical to the 
definition of the layer20ctetDeltaCount Information Element, 


except that it reports a potentially modified value caused by a 
middlebox function after the packet passed the Observation Point. 


This Information Element is the layer 2 version of 
postOctetDeltaCount (ElementId #23). 


Abstract Data Type: unsigned64 

Data Type Semantics: deltaCounter 

Element Ld: 417 

References: [RFC5477] 

Status: current 

Units: octets 

3.2.10. postMCastL20ctetDeltaCount 

Description: 
The number of layer 2 octets since the previous report (if any) in 
outgoing multicast packets sent for packets of this Flow by a 
multicast daemon within the Observation Domain. This property 
cannot necessarily be observed at the Observation Point but may be 
retrieved by other means. The number of octets includes layer 2 


header(s) and layer 2 payload. 


This Information Element is the layer 2 version of 
postMCastOctetDeltaCount (ElementId #20). 


Abstract Data Type: unsigned64 
Data Type Semantics: deltaCounter 


ElementId: 418 
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References: [RFC5477] 
Status: current 
Units: octets 
3.2.11. postL20ctetTotalCount 
Description: 
The definition of this Information Element is identical to the 
definition of the layer20ctetTotalCount Information Element, 


except that it reports a potentially modified value caused by a 
middlebox function after the packet passed the Observation Point. 


This Information Element is the layer 2 version of 
postOctetTotalCount (ElementId #171). 


Abstract Data Type: unsigned64 

Data Type Semantics: totalCounter 

Elementld: 420 

References: [RFC5477] 

Status: current 

Units: octets 

3.2.12. postMCastL20ctetTotalCount 

Description: 
The total number of layer 2 octets in outgoing multicast packets 
sent for packets of this Flow by a multicast daemon in the 
Observation Domain since the Metering Process (re-)initialization. 
This property cannot necessarily be observed at the Observation 
Point but may be retrieved by other means. The number of octets 


includes layer 2 header(s) and layer 2 payload. 


This Information Element is the layer 2 version of 
postMCastOctetTotalCount (ElementId #175). 


Abstract Data Type: unsigned64 


Data Type Semantics: totalCounter 
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Elementld: 421 
References: [RFC5477] 
Status: current 
Units: octets 
3.2.13. minimumL2TotalLength 


Description: 


Layer 2 length of the smallest packet observed for this Flow. The 
packet length includes the length of the layer 2 header(s) and the 
length of the layer 2 payload. 


This Information Element is the layer 2 version of 
minimumIpTotalLength (ElementId #25). 


Abstract Data Type: unsigned64 
Elementld: 422 
References: [RFC5477] 
Status: current 
Units: octets 
3.2.14. maximumL2TotalLength 


Description: 


Layer 2 length of the largest packet observed for this Flow. The 
packet length includes the length of the layer 2 header(s) and the 
length of the layer 2 payload. 


This Information Element is the layer 2 version of 
maximumIpTotalLength (ElementId #26). 


Abstract Data Type: unsigned64 
Elementld: 423 


References: [RFC5477] 
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Status: current 
Units: octets 
3.2.15. droppedL20ctetDeltaCount 
Description: 
The number of layer 2 octets since the previous report (if any) in 
packets of this Flow dropped by packet treatment. The number of 


octets includes layer 2 header(s) and layer 2 payload. 


This Information Element is the layer 2 version of 
droppedOctetDeltaCount (ElementId #132). 


Abstract Data Type: unsigned64 

Data Type Semantics: deltaCounter 

Elementld: 424 

References: [RFC5477] 

Status: current 

Units: octets 

3.2.16. droppedL20ctetTotalCount 

Description: 
The total number of octets in observed layer 2 packets (including 
the layer 2 header) that were dropped by packet treatment since 


the (re-)initialization of the Metering Process. 


This Information Element is the layer 2 version of 
droppedOctetTotalCount (ElementId #134). 


Abstract Data Type: unsigned64 
Data Type Semantics: totalCounter 
Elementld: 425 


References: [RFC5477] 
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Status: current 


Units: octets 


3.2.17. ignoredL20ctetTotalCount 


Description: 


The total number of octets in observed layer 2 packets (including 
the layer 2 header) that the Metering Process did not process 
since the (re-)initialization of the Metering Process. 


This Information Element is the layer 2 version of 
ignoredOctetTotalCount (ElementId #165). 


Abstract Data Type: unsigned64 
Data Type Semantics: totalCounter 
Elementld: 426 

References: [RFC5477] 

Status: current 


Units: octets 


3.2.18. notSentL20ctetTotalCount 


Description: 
The total number of octets in observed layer 2 packets (including 
the layer 2 header) that the Metering Process did not process 


since the (re-)initialization of the Metering Process. 


This Information Element is the layer 2 version of 
notSentOctetTotalCount (ElementId #168). 


Abstract Data Type: unsigned64 
Data Type Semantics: totalCounter 
Elementld: 427 


References: [RFC5477] 
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Status: current 
Units: octets 
3.2.19. layer2O0ctetDeltaSumOfSquares 
Description: 
The sum of the squared numbers of layer 2 octets per incoming 
packet since the previous report (if any) for this Flow at the 
Observation Point. The number of octets includes layer 2 


header(s) and layer 2 payload. 


This Information Element is the layer 2 version of 
octetDeltaSumOfSquares (ElementId #198). 


Abstract Data Type: unsigned64 

Data Type Semantics: deltaCounter 

Elementld: 428 

References: [RFC5477] 

Status: current 

Units: octets 

3.2.20. layer2OctetTotalSumOfSquares 

Description: 
The total sum of the squared numbers of layer 2 octets in incoming 
packets for this Flow at the Observation Point since the Metering 
Process (re-)initialization for this Observation Point. The 


number of octets includes layer 2 header(s) and layer 2 payload. 


This Information Element is the layer 2 version of 
octetTotalSumOfSquares (ElementId #199). 


Abstract Data Type: unsigned64 
Data Type Semantics: totalCounter 
ElementId: 429 


References: [RFC5477] 
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Status: current 
Units: octets 


4. Modification of Existing Information Elements Related to Packet 
Section 


The new Information Elements related to packet section (i.e., 
sectionOffset and sectionExportedOctets) can be applied to not only 
dataLinkFrameSection but also to all kinds of packet section (i.e., 
ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection, 


and mplsPayloadPacketSection defined in [RFC5477]). Therefore, 
existing Information Elements Descriptions should be modified as 
follows. 

4.1. ipHeaderPacketSection 
This Information Element is defined in [RFC5477]. The description 


has been updated from [RFC5477]. 
Description: 


This Information Element carries a series of n octets from the IP 
header of a sampled packet, starting sectionOffset octets into the 
IP header. 


However, if no sectionOffset field corresponding to this 
Information Element is present, then a sectionOffset of zero 
applies, and the octets MUST be from the start of the IP header. 


With sufficient length, this element also reports octets from the 
IP payload. However, full packet capture of arbitrary packet 
streams is explicitly out of scope per the Security Considerations 
sections of [RFC5477] and [RFC2804]. 


The sectionExportedOctets expresses how much data was exported, 
while the remainder is padding. 


When the sectionExportedOctets field corresponding to this 
Information Element exists, this Information Element MAY have a 
fixed length and MAY be padded, or it MAY have a variable length. 


When the sectionExportedOctets field corresponding to this 
Information Element does not exist, this Information Element 
SHOULD have a variable length and MUST NOT be padded. In this 
Case, the size of the exported section may be constrained due to 
limitations in the IPFIX protocol. 
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Abstract Data Type: octetArray 
Elementld: 313 
References: [RFC2804] [RFC5477] 
Status: current 

4.2. ipPayloadPacketSection 


This Information Element is defined in [RFC5477]. The description is 
updated from [RFC5477]. 


Description: 


This Information Element carries a series of n octets from the IP 
payload of a sampled packet, starting sectionOffset octets into 
the IP payload. 


However, if no sectionOffset field corresponding to this 
Information Element is present, then a sectionOffset of zero 
applies, and the octets MUST be from the start of the IP payload. 


The IPv4 payload is that part of the packet that follows the IPv4 
header and any options, which [RFC0791] refers to as "data" or 
"data octets". For example, see the examples in [RFC0791], 
Appendix A. 


The IPv6 payload is the rest of the packet following the 40-octet 
IPv6 header. Note that any extension headers present are 
considered part of the payload. See [RFC2460] for the IPv6 
specification. 


The sectionExportedOctets expresses how much data was observed, 
while the remainder is padding. 


When the sectionExportedOctets field corresponding to this 
Information Element exists, this Information Element MAY have a 
fixed length and MAY be padded, or it MAY have a variable length. 


When the sectionExportedOctets field corresponding to this 
Information Element does not exist, this Information Element 
SHOULD have a variable length and MUST NOT be padded. In this 
case, the size of the exported section may be constrained due to 
limitations in the IPFIX protocol. 
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Abstract Data Type: octetArray 
Elementld: 314 
References: [REC0791] [RFC2460] 
Status: current 

4.3. mplsLabelStackSection 


This Information Element is defined in [RFC5477]. The description is 
updated from [RFC5477]. 


Description: 


This Information Element carries a series of n octets from the 
MPLS label stack of a sampled packet, starting sectionOffset 
octets into the MPLS label stack. 


However, if no sectionOffset field corresponding to this 
Information Element is present, then a sectionOffset of zero 
applies, and the octets MUST be from the head of the MPLS label 
stack. 


With sufficient length, this element also reports octets from the 
MPLS payload. However, full packet capture of arbitrary packet 
streams is explicitly out of scope per the Security Considerations 
sections of [RFC5477] and [RFC2804]. 


See [RFC3031] for the specification of MPLS packets. 
See [RFC3032] for the specification of the MPLS label stack. 


The sectionExportedOctets expresses how much data was observed, 
while the remainder is padding. 


When the sectionExportedOctets field corresponding to this 
Information Element exists, this Information Element MAY have a 
fixed length and MAY be padded, or it MAY have a variable length. 


When the sectionExportedOctets field corresponding to this 
Information Element does not exist, this Information Element 
SHOULD have a variable length and MUST NOT be padded. In this 
case, the size of the exported section may be constrained due to 
limitations in the IPFIX protocol. 
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Abstract Data Type: octetArray 
ElementId: 316 
References: [RFC2804] [RFC3031] [RFC3032] [RFC5477] 
Status: current 
4.4. mplsPayloadPacketSection 


This Information Element is defined in [RFC5477]. The description is 
updated from [RFC5477]. 


Description: 


The mplsPayloadPacketSection carries a series of n octets from the 
MPLS payload of a sampled packet, starting sectionOffset octets 
into the MPLS payload, as it is data that follows immediately 
after the MPLS label stack. 


However, if no sectionOffset field corresponding to this 
Information Element is present, then a sectionOffset of zero 
applies, and the octets MUST be from the start of the MPLS 
payload. 


See [RFC3031] for the specification of MPLS packets. 
See [RFC3032] for the specification of the MPLS label stack. 


The sectionExportedOctets expresses how much data was observed, 
while the remainder is padding. 


When the sectionExportedOctets field corresponding to this 
Information Element exists, this Information Element MAY have a 
fixed length and MAY be padded, or it MAY have a variable length. 


When the sectionExportedOctets field corresponding to this 
Information Element does not exist, this Information Element 
SHOULD have a variable length and MUST NOT be padded. In this 
case, the size of the exported section may be constrained due to 
limitations in the IPFIX protocol. 

Abstract Data Type: octetArray 


Elementld: 317 


Kashima, et al. Standards Track [Page 25] 


RFC 7133 Data Link Layer Information Elements May 2014 


References: [RFC3031] [RFC3032] 
Status: current 
5. Modification of Existing Information Elements Related to VLAN Tag 


The traffic measurement using IPFIX and PSAMP for a Provider Backbone 
Bridged Network requires the Information Elements related to Backbone 
Service Instance Tag (I-TAG) and Backbone VLAN Tag (B-TAG). The set 
of Information Elements related to I-TAG is added in Section 3, 
because I-TAG structure and semantics are different from that of 
Service VLAN Tag (S-TAG) and Customer VLAN Tag (C-TAG). The set of 
Information Elements related to B-TAG reuses the existing Information 
Elements, because B-TAG structure and semantics are identical to that 
of C-TAG and S-TAG. This section modifies existing descriptions and 
references related to C-TAG and S-TAG as follows. 


5.1. dotlaqVlanld 
Description: 


The value of the 12-bit VLAN Identifier portion of the Tag Control 
Information field of an Ethernet frame. The structure and 
semantics within the Tag Control Information field are defined in 
[IEEE802.10]. In Provider Bridged Networks, it represents the 
Service VLAN identifier in the Service VLAN Tag (S-TAG) Tag 
Control Information (TCI) field or the Customer VLAN identifier in 
the Customer VLAN Tag (C-TAG) Tag Control Information (TCI) field 
as described in [IEEE802.10]. In Provider Backbone Bridged 
Networks, it represents the Backbone VLAN identifier in the 
Backbone VLAN Tag (B-TAG) Tag Control Information (TCI) field as 
described in [IEEE802.10]. In a virtual link between a host 
system and EVB bridge, it represents the Service VLAN identifier 
indicating S-channel as described in [IEEE802.10bg]. 


In the case of a multi-tagged frame, it represents the outer tag’s 
VLAN identifier, except for I-TAG. 


Abstract Data Type: unsignedl6 
Data Type Semantics: identifier 
Elementld: 243 
Status: current 


References: [IEEE802.10] [IEEE802.10bg] 
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5.2. dotlqPriority 
Description: 
The value of the 3-bit User Priority portion of the Tag Control 
Information field of an Ethernet frame. The structure and 
semantics within the Tag Control Information field are defined in 
[IEEE802.10]. In the case of a multi-tagged frame, it represents 
the 3-bit Priority Code Point (PCP) portion of the outer tag’s Tag 
Control Information (TCI) field as described in [IEEE802.10], 
except for I-TAG. 
Abstract Data Type: unsigned8 
Data Type Semantics: identifier 
Elementld: 244 
Status: current 
References: [IEEE802.10] 
5.3. dotlaCustomerVlanld 
Description: 
The value represents the Customer VLAN identifier in the Customer 
VLAN Tag (C-TAG) Tag Control Information (TCI) field as described 
in [IEEE802.10]. 
Abstract Data Type: unsignedl6 
Data Type Semantics: identifier 
Elementld: 245 
Status: current 
References: [IEEE802.10] 
5.4. dotlqCustomerPriority 
Description: 
The value represents the 3-bit Priority Code Point (PCP) portion 


of the Customer VLAN Tag (C-TAG) Tag Control Information (TCI) 
field as described in [IEEE802.10]. 
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Abstract Data Type: unsigned8 
Data Type Semantics: identifier 
Elementld: 246 

Status: current 

References: [IEEE802.10] 


6. The Relationship between Ethernet Header Fields and Information 
Elements 


The following figures show a summary of various Ethernet header 
fields and the Informational Elements that would be used to represent 
each of the fields. 


<-- 6 ==> <-- 6 --> <-- 4 --> <---- 2 ----> 
十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 十 
| C-DA | C-SA | C-TAG | Length/Type | 
| a | b | c | d | 
十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 十 
a. (Information Element) destinationMacAddress (80) 
b. (Information Element) sourceMacAddress (56) 
c. (Information Elements) dotlqVlanId (243), dotlgPriority (244) 
d. (Information Element) ethernetType (256) 
Figure 1: Customer-Tagged Frame Header Fields 
<==: 6 ==> <== 6 ==> <== 4 --> <-- 4 --> <---- 2 ===> 
十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 十 
| C-DA | C-SA | S-TAG | C-TAG | Length/Type | 
| a | b | c | d | e | 
十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 十 
a. (Information Element) destinationMacAddress (80) 
b. (Information Element) sourceMacAddress (56) 
Cc. (Information Elements) dotlqVlanId (243), dotlgqPriority (244) 
d. (Information Elements) dotlqCustomerVlanId (245), 
dotiqCustomerPriority (246) 
e. (Information Element) ethernetType (256) 


Figure 2: Service-Tagged Frame Header Fields 
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<-- 6 ==> <-- 6 --> <-- 4 --> <--- 16 ---> <-- 4 --> <---- 2 ----> 
d EE daare Ho === =25=2=>== 5 SS === == === See oS sees + 
B-DA B-SA B-TAG I-TAG C-TAG Length/Type 

| a | b f cœ | a | e | f 
Ho Ho Ho +------------ Ho $ EE SE + 
a. (Information Element) destinationMacAddress (80) 
b. (Information Element) sourceMacAddress (56) 

Cc. (Information Elements) dotlqVlanId (243), dotlgqPriority (244) 
d. (Information Elements) dotlqServiceInstanceTag (411), or 


a set of dotlgServicelnstanceld (412), 
dotligqServiceInstancePriority (413), 
dotlqCustomerSourceMacAddress (414) 
dotiqCustomerDestinationMacAddress (415), 
e. (Information Elements) dotlqCustomerVlanId (245), 
dotliqCustomerPriority (246) 
f. (Information Element) ethernetType (256) 


Figure 3: Backbone-VLAN-Tagged Frame Header Fields 
7. Security Considerations 


Reporting more granular data may increase the risk of DoS attacks 
against a Collector. Protection against DoS attacks is discussed in 
Section 11.4 of [RFC7011]. 


The recommendations in this document do not otherwise introduce any 
additional security issues beyond those already mentioned in 
[RFC7011] and [RFC5477]. 


8. IANA Considerations 


Existing IPFIX Information Elements [IANA-IPFIX] have been modified 
as indicated in Sections 3.1, 4, and 5. 


Per Section 5.2 of [RFC7013], for each of these changes, [RFC7133] 
has been appended to the Requester in IANA’s IPFIX registry 
[IANA-IPFIX], the Information Element’s Revision number has been 
incremented by one, and the Information Element’s revision Date 
column has been updated. 


New IPFIX Information Elements [IANA-IPFIX] have been allocated as 
shown in Section 3.2. 
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Appendix A. Frame Formats 


| 

十 LA 
| 
| 

+ LA 
| 


C-DA 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
C-SA 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
Length/Type 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


:一 + 一 + 一 + 一 + 一 + oo 


:一 十 一 十 一 十 一 十 一 十 


Customer Data 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure A-1: Untagged Frame Format 


l 
+ LA 
l 


C-DA 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
C-SA 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
C-TAG TPID=0x8100 |c-PcP |c] C-VID 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
Length/Type | 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


:一 + 一 + 一 + 一 + 一 + 一 + 口 品 


:一 + 一 + 一 + 一 + 一 + 一 十 


Customer Data 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure A-2: C-TAG Tagging Frame Format 
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l 
+ P 
l 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
C-SA 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
S-TAG TPID=0x88a8 |s-PcP |D] S-VID 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
Length/Type | 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


:一 + 一 + 一 + 一 + 一 + 一 + 口 品 


:一 + 一 + 一 + 一 + 一 + 一 十 


Customer Data 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure A-3: S-TAG Tagging Frame Format in Provider Bridged Networks 


+ 

C-DA | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 

+ 

| 


一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
C-SA 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
S-TAG TPID=0x88a8 |s-PcP |D| S-VID 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
C-TAG TPID=0x8100 |c-PcP |c] C-VID 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

Length/Type | 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


:一 + 一 + 一 + 一 + 一 + 一 + 一 + oo 


1 一 十 一 


Customer Data 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure A-4: S-TAG and C-TAG Tagging Frame Format in Provider Bridged 
Networks 
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一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
B-SA 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
B-TAG TPID=0x88a8 |B-PCP |D| B-VID 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
I-TAG TPID=0x88e7 |I-pcP|D|u| Res I-SID 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
I-SID | | 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 + 
C-DA | 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
C-SA | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Length/Type | 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


:一 + 一 + 一 + 一 + 一 + 一 + 一 + 一 + 一 + 一 + 口 口 


Customer Data 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure A-5: B-TAG and I-TAG Tagging Frame Format in Provider Backbone 
Bridged Networks 


Kashima, et al. Standards Track [Page 34] 


RFC 7133 Data Link Layer Information Elements May 2014 


一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
B-SA 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
B-TAG TPID=0x88a8 |B-PCP |D| B-VID 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
I-TAG TPID=0x88e7 |I-pcP|D|u| Res I-SID 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
I-SID | | 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 + 
C-DA | 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
C-SA | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| C-TAG TCI=0x8100 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
|c-PcP|c| C-VID | Length/Type 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | 


Customer Data A 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


一 + 一 + 一 + 一 + 一 + 一 + 一 + 一 + 一 + 00 


Figure A-6: B-TAG, I-TAG, and C-TAG Tagging Frame Format in Provider 
Backbone Bridged Networks 
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l 
E P 
l 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
C-SA 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
S-TAG TPID=0x88a8 |s-PcP |D| S-VID 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
Length/Type | 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


:一 + 一 + 一 + 一 + 一 + 一 + 口 品 


:一 + 一 + 一 + 一 + 一 + 一 十 


Customer Data 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure A-7: S-TAG Tagging Frame Format for S-channel over the Link 
between an End Station and Its Adjacent Bridge 


Note: The frame format in Figure A-7 is identical to the format in 
Figure A-3. 
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一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
C-SA 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
S-TAG TPID=0x88a8 |s-PcP |D| S-VID 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
C-TAG TPID=0x8100 |c-PcP |c] C-VID 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

Length/Type | 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


:一 + 一 + 一 + 一 + 一 + 一 + 一 + 00 


:一 + 一 


Customer Data 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure A-8: S-TAG and C-TAG Tagging Frame Format over the Link 
between an End Station and Its Adjacent Bridge 


Note: The frame format in Figure A-8 is identical to the format in 
Figure A-4. 
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l 
E P 
l 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
C-SA 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
E-TAG TPID=0x893F |E-PCP |D| Ingress_E-CID_base 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
s|GRP | E-CID_base | Ingre_E-CID_ext | E-CID_ext 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
Length/Type | 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


R 


:一 + 一 + 一 + 一 + 一 + 一 + 一 + 口 口 
+0 + 


:一 + 一 + 一 + 一 + 一 + 一 + 一 十 


Customer Data 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure A-9: E-TAG Tagging Frame Format over the Link between a 
Controlling Bridge and a Bridge Port Extender 
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l 
E P 
l 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
C-SA 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
E-TAG TPID=0x893F |E-PCP |D| Ingress_E-CID_base 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 

s |GRP | E-CID_base | Ingre_E-CID_ext | E-CID_ext 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
C-TAG TPID=0x8100 |c-PcP|c| C-VID 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 

Length/Type | 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


R 


:一 + 一 + 一 + 一 + 一 + 一 + 一 + 一 + 00 
+0 + 


:一 + 一 + 一 + 一 + 一 + 一 + 一 + 一 十 


Customer Data 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure A-10: E-TAG and C-TAG Tagging Frame Format over the Link 
between a Controlling Bridge and a Bridge Port Extender 
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Appendix B. Template Format Example 
0 1 
O I 2.3436. .78970 12.3.4 5 6 7-8 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Set ID (2) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Template ID (256) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| ingressInterface (10) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| egressInterface (14) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| observationTimeSeconds (322) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| dataLinkFrameSize (312) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| dataLinkFrameSection (315) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| dataLinkFrameType (408) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| sectionOffset (409) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| sectionExportedOctets (410) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
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Figure B-1: 


Template 


2 
90123456 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 

Length 


Field Count (8) 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
Field Length (4) 
Field Length (4) 
Field Length (8) 


Field Length (2) 


Field Length (2) 
Field Length (2) 


Field Length (2) 


Format Example 


Standards Track 


J 


+ 


+ 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
Field Length (65535) 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


OO 


十 


十 


十 


十 


LO 


一 十 一 


一 十 一 


一 十 一 


一 十 一 


一 十 一 


一 十 一 


一 十 一 


一 十 一 


一 十 一 
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十 一 十 一 十 


十 一 十 一 十 


十 一 十 一 十 


十 一 十 一 十 


十 一 十 一 十 


十 一 十 一 十 


十 一 十 一 十 


十 一 十 一 十 


十 一 十 一 十 


十 一 十 一 十 
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